When a security relevant software runs on a software controllable device, wherein the software is, for example, indispensible for a reliable and secure function of the device and assuring the function is a prerequisite for operating the device, it has to be assured that the security relevant software is not rendered dysfunctional through external interferences, for example, through other software which also runs together with the security relevant software on a computer of the device. Interferences of this type can occur, for example, when the non-security relevant software changes or deletes information (data or commands) of the security relevant software that is stored in an intermediary manner in a user memory.
Therefore security relevant software has to be separated from non-security relevant software physically and also time-based in order to exclude mutual influencing among other things in case of an error. This is required for a proof of security as it has to be provided to some extent for IEC 61 508, a standard for security relevant programmable systems.
In a scenario that will be described infra it is presumed that a multitasking capable operating system is operated on a system without sufficient security integrity. The operating system has complete access to the entire hardware. A security relevant component shall be executed on the system. The security relevant component does not use any services or functions of the operating system for performing its function.
Though no separation is provided between components, a security relevant component shall be able to assure its own integrity and thus security at all times.
Without separation, components rated at a lower level have complete access to the memory of the security relevant component. Thus, any memory contents of the security relevant component can be written over due to an error. This may have no consequences in a best case scenario, it may lead to a crash of the security relevant component or it may also impair the function and the behavior of the security relevant component. The two latter cases are risky and have to be avoided. This risk can be mitigated by assuring the memory's integrity.
Memory integrity means that the condition of one component, the memory associated with one component can only be changed by executing the component itself and cannot be changed by third parties. This assures that the security relevant component always performs the function implemented therein and no other function. The points in time at which the memory integrity can be violated can be clearly limited. Violations can occur when lower rated components are executed. Thus system integrity only has to be provided exactly when the security relevant component is not active.
FIG. 1 illustrates a known control device 1 including a processer 10 and a security relevant operating system 11 which is certified for assuring memory integrity and a security relevant and certified first control unit 12 and another non-security relevant and thus non-certified control unit 13. The control units 12, 13 are respectively connected with sensors 14, 15 and respectively put out signals to actuators 16, 17.
FIG. 2 illustrates a known control device 2 as an alternative design for a secure computer system which includes two processers 20, 21. An independent operating system 22, 23 runs on each of the processers and each of the processors includes a proprietary control unit 24, 25. In order to provide the required security, the processer 20 is provided with a security relevant operating system 22 and a security relevant control unit 24. The security relevant operating system 22 and also the security relevant control unit 24 have to be certified according to the respectively applicable security regulations, for example, according to IEC 61 508. The control units 24, 25 are respectively connected with sensors 16, 27 and respectively put out signals to actuators 28, 29. The configuration in FIG. 2 furthermore requires that a memory management unit (MMU) is provided on the hardware platform. Without a MMU the software that is not security relevant per se becomes security relevant.
FIG. 3 illustrates a known control device representing another configuration of a secure computer system, wherein the control device includes two hardware configurations 30, 31 that are independent from one another, wherein one hardware configuration 30 is certified. The certified hardware configuration includes a hardware control unit which is configured as a certified security relevant control unit 32. The other non-security relevant hardware configuration 31 includes an operating system 33 and a control unit 34 configured as software. The two hardware configurations 30, 31 are respectively connected with sensors 36, 37 for providing input signals and are respectively connected with actuators 38, 39 for putting out control signals.
As an alternative to the operating system typically a security relevant hypervisor is being used. The hypervisor can either play the role of an operating system like in FIG. 2 or execute two different operating systems, wherein one of them is security relevant or it can simulate two discreet hardware platforms as illustrated in FIG. 3 on which operating systems are executed respectively.
The known designs for secure computer systems have complex configurations and high certification complexity.